REMARKS 

The above amendment is made in response to the Office Action mailed April 20, 
2006. Claims 1-6, and 8-9 are pending in the present application and stand rejected. 
Claims 1, 3, 4, and 8-9 have been amended. The Examiner's reconsideration is respectfully 
requested in view of the following remarks. 

Prelude 

At the outset, it should be noted that Applicants strongly disagree with the 
Examiner's assertions on page 2 of the Office Action. For instance, the Appeal Brief 
clearly explains, not merely alleges, how Lonnroth fails to teach the claimed inventions 
(See pages 6-16). Moreover, Section 5, Summary of the Claimed Subject Matter in the 
Appeal Brief, shows support for the claimed inventions by Appellant's specification. 

Drawing Objections - 37 CFR 1.83(a) 

In paragraph 3, the Examiner stated that the drawings do not show the "device- 
platform interface sending the XML requests to a platform kernel section via HTTP 
protocol" This assertion is incorrect because all of these elements are shown in FIG. 1 . 
The "device-platform interface" is defined in page 6, lines 9-1 1 of the specification to be 
the same as the "Device Abstraction Layer (DAL)" as illustrated in FIG.l . The "platform 
kernel" is defined in page 10, lines 15-19 of the specification as comprising "a service 
engine 101, a runtime monitor 102, profile manager 103, and auxiliary components 104 
(such as a security manager 104a, and a billing manager 104b, etc.)", which are clearly 
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illustrated in FIG. 1 . Further, a double sided arrow labeled "XML" between "DAL" and 
the service engine 102 is illustrated in FIG.l . Since the service engine 102 is part of the 
"platform kernel" section, FIG. 1 clearly illustrates a "device-platform interface" (DAL) 
sending the "XML" requests to a "platform kernel" section via HTTP protocol. 

The Examiner further stated that the drawings do not show "the platform kernel 
section providing one of a synchronized and an asynchronized service engine." This 
assertion is incorrect because these elements are shown in FIG. 1 . Additionally, FIG. 1 
illustrates a "service engine 101" which as described above, is part of the "platform kernel" 
section. FIG. 1 further illustrates that the service engine comprises a queue manager and a 
session manager. The "service engine 101" is described as "providing both a synchronized 
and asynchronized service engine" on page 10, lines 25-26 of the specification. Claim 4 
recites a synchronized service engine providing requests managed by a session (i.e., 
session manager of service engine 101 in FIG. 1) and asynchronized requests managed by 
a queue (queue manager of service engine 101 in FIG. 1). 

Accordingly, for the reasons discussed above, withdrawal of the objections under 
37 CFR 1.83(a) is respectively requested. 

Claim Rejections - § 112, first paragraph 

Claim 1 stands rejected under 35 U.S.C 1 12, first paragraph as failing to comply 
with the written description requirement for the reasons set forth on pages 4-5 of the Office 
Action. 

In assessing whether a specification satisfies the "written description" requirement 
under 35 U.S.C. 1 12, first paragraph, with respect to the claimed invention(s), the 
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fundamental factual inquiry is whether the patent specification describes the claimed 
invention with reasonable clarity such that one of ordinary skill in the art can reasonably 
conclude that the inventor(s) had possession of the claimed invention as of the filing date 
of the specification. See Vas-Cath f Inc. v. Mahurkar, 935 F.2d 1555, 1563-64 (Fed Cir. 
1991). Compliance with the written description requirement is a question of fact which is 
resolved on a case by case basis. See Vas-Cath, 935 F.2d at 1562-63. 

An applicant shows possession of the claimed invention by describing the claimed 
invention with all of its limitations using "such descriptive means as words, structures, 
figures, diagrams, etc., that fully set forth the claimed invention." Lockwood v. American 
Airlines, Inc. 107 F.3d 1565, 1572 (Fed. Cir. 1997). However, compliance with the written 
description requirement does not compel use of any particular form of description, so long 
as the description clearly allows one of ordinary skill in the art to recognize that the 
applicant invented what is defined by the patent claims. See In Re Alton, 76 F.3d 11 68, 
1172 (Fed. Cir.' 1996). 

Indeed, it is well established that the subject matter of the claim need not be 
described literally (i.e., using the same terms or in haec verba) in order for the disclosure 
to satisfy the description requirement. See Purdue Pharma L.P. v. Faulding Inc., 230 F.3d 
1320, 1323 (Fed. Cir. 2000). The written description requirement may be met by 
disclosure that is "inherent" in the specification where a person of ordinary skill in the art 
would recognize such disclosure upon reviewing the specification. See Reiffin v. Microsoft 
Corp., 214 F.3d 1342, 1345-46 (Fed. Cir. 2000) (citing Continental Can Co. USA v. 
Monsanto Co., 948 F.2d 1264, 1268 (Fed. Cir. 1991)). "If a person of ordinary skill in 
the art would have understood the inventor to have been in possession of the claimed 
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invention at the time of filing, even if every nuance of the claims is not explicitly described 
in the specification, then the adequate description is met." In re Alton, 76 F,3d at 1 175 
(see also Vas-Cath, 935 F.2d at 1563). Furthermore, information that is well-known in 
the art need not be described in detail in the specification and the specification need only 
describe in detail that which is new or not conventional. See Hybritech, Inc. v. 
Monoclonal Antibodies, Inc. 802 F.2d 1367, 1379-80 (Fed. Cir. 1986). 

Here, at the very least, the specification as originally filed contains sufficient 
disclosure, either expressly or inherently, to support the invention of Claim 1 under the 
"written description" requirement of 35 U.S.C. 1 12, first paragraph. 

In paragraph 6, the Examiner stated that the " device-platform interface is never 
actually used anywhere in the applicant 's specification other than the Abstract and the 
claims themselves" and "can only be interpreted as the Device Abstraction Layer" . This 
assertion is incorrect because the " device-platform interface " is used on page 6, line 10 of 
the specification and is further described on page 6, lines 9-1 1 of the specification as the 
Device Abstraction Layer (DAL). 

Further in paragraph 6, the Examiner stated that the "platform kernel section is 
never used anywhere in the Applicant's disclosure except for the claims" and "can only be 
interpreted as the Kernel Service Engine " This assertion is incorrect because the term 
"platform kerneF is used on page 10, line 16 of the specification, and is further described 
on page 10, lines 15-19 of the specification as comprising, for example elements 101-103 
andl04a-b of FIG. 1. 

In paragraph 7, the Examiner stated that the "[f]or the Device Abstraction Layer to 
send XML requests to the Kernel Service Engine via HTTP protocol, as claimed by the 



10 



applicant, the Kernel Service Engine would have to include a web server program and the 
Device Abstraction Layer would have to include a web client program" and "[njowhere in 
the applicants specification is there a web server described on the Kernel Service Engine or 
a web client described in the Device Abstraction Layer". These assertions are incorrect, 
and based solely on the opinion of the Examiner, but not on what would be known by one 
of ordinary skill in the art. In fact, FIG. 1 does illustrate a web application server. In any 
event, claim 1 was amended to remove the phrase "via HTTP protocol" to broaden the 
claim, as any suitable method or protocol may be used. 

Further in paragraph 7, the Examiner stated that since "there is no hint as to how or 
even why the HTTP protocol is incorporated" and "[s]uch an omission fails to place the 
public in possession of the applicant's invention". This assertion is incorrect because, at 
the very least, it is based on an erroneous standard of law. As described above, the correct 
the standard of inquiry is whether the patent specification describes the claimed invention 
with reasonable clarity such that one of ordinary skill in the art can reasonably conclude 
that the inventor(s) had possession of the claimed invention (e.g., HTTP protocol) as of the 
filing date of the specification. Further, HTTP is described on page 3, lines 6-14, page 8, 
lines 16-21, and page 9, lines 19-23 in the specification. In any event, as described above, 
claim 1 was amended to remove the phrase "via HTTP protocol to broaden the claim. 

In paragraph 8, the Examiner took issue with the use of "representation mode". 
Claim 1 has been amended to address this issue and is supported by page 2, line 23-page 3, 
line 8 of the specification. 

Accordingly, for the reasons discussed above, withdrawal of the claim rejections 
under 35 U.S.C. § 112, first paragraph is respectfully requested. 
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Claim Rejections - § 112, second paragraph 

Claims 1, 2, 4-6, 8-9 stand rejected under 35 U.S.C 1 12, second paragraph, for the 
reasons forth on pages 5-8 of the Office Action. With regard to claim 1, the Examiner 
contended that essential structural cooperative relationships were omitted. Each of the 
structural relationships that the Examiner took issue with are addressed below. 

In paragraph 12, the Examiner stated that the " service-platform interface is never 
claimed as interacting with any of the other claim elements so it is unclear what its 
purpose is for being claimed*' and it "is only mentioned in the claims so it cannot be 
interpreted in light of the specification" These assertions are incorrect. Line 13, page 6 of 
the specification inadvertently swapped the terms 'platform 5 and 'service' resulting in 
'platform-service interface" instead of the intended "service-platform interface". The 
specification has been amended to address this issue. On page 6, lines 12-14 of the 
specification, the "service-platform interface" is defined to be the service abstraction layer 
or SAL, and clearly interacts with claim elements as illustrated in FIG. 1 . 

In paragraph 13, the Examiner stated that "[a] second platform kernel section is 
defined in the final limitation of claim 1 " and "[i]t is unclear whether this second platform 
kernel section is intended to be the same as the previously mentioned platform kernel 
section" Claim 1 has been amended to address this issue. 

In paragraph 14, the Examiner stated that "the platform kernel section provides one 
of a synchronized and an asynchronized service engine", but "it is completely unclear how 
the asynchronized service engine works or how it relates [to] the synchronized engine." 
These assertions are incorrect because there is disclosure (in page 3, lines 15-20) in the 
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specification of the kernel service engine. Additionally, at the time of the invention it was 
known in the art that asynchronous services are characterized by a client invoking a service 
but lacking the ability to wait for the response, whereas synchronous services are 
characterized by the client invoking a service and then waiting for a response. Further, 
FIG. 1 shows that the asynchronized service engine does not have to work with the 
synchronized service engine. 

In paragraph 15, the Examiner stated that claim 1 lacks antecedent basis for the 
limitation of "the adapter for transforming between service responses issued by the 
services and the XML response." As rationale, the Examiner stated that ''because the XML 
responses are only previously claimed as being sent to the device specific-platform 
interface so it is unclear how they could then be transformed at the service-platform 
interface" This assertion is incorrect because claim 1 recites, inter alia, "sending the XML 
requests to a platform kernel section" and not sending XML responses. Furthermore, claim 
1 recites inter alia, "XML responses which are returned by the platform kernel section" 
and FIG. 1 shows a bi-directional arrow labeled XML between the service-platform 
interface and the platform kernel section. Therefore, claim 1 does not lack antecedent 
basis. This claim has dual support for the reasons give above. 

In paragraph 16, with regard to claims 2 and 5, the Examiner stated that "claims 2 
and 5 recite the limitations the user information, the device information, and the service 
information" and there "is insufficient antecedent basis for this limitation" However, 
claims 2 and 5 depend on base claim 1, which recites inter alia, "wherein the platform 
kernel section is for managing user information, device information and service 
information". Therefore, claims 2 and 5 do not lack antecedent basis. 



13 



In paragraph 17, the examiner stated that claim 4 is rejected because "it is unclear 
how a request can be based on a queue." At the time of the invention, it was known in the 
art that when a request is based on a queue or is queue-based, the requests may be handled 
or managed by a queue. Claim 4 has been amended to recite inter alia, ''asynchronized 
requests managed by a queue" merely to clarify, and does not add new matter as FIG.l 
illustrates the service engine comprises a queue manager. 

In paragraph 18, the Examiner stated that ''said device information" lacks 
antecedent basis in claim 6. However, there is sufficient antecedent basis because claim 6 
depends on base claim 1, which recites inter alia, "wherein the platform kernel section is 
for managing user information, device in formation and service information 

In paragraph 19 the Examiner stated that "said device information" lacks 
antecedent basis in claim 8. However, there is sufficient antecedent basis because claim 8 
depends from base claim 1 , which recites inter alia, "wherein the platform kernel section is 
for managing user information, device in formation and service information " 

In paragraph 20, the Examiner stated that "the back-end of the platform" lacks 
antecedent basis in claim 8. Claim 8 has been amended to address this issue. 

In paragraph 21, the Examiner stated that "said service information" lacks 
antecedent basis in claim 9. However, there is sufficient antecedent basis because claim 9 
depends from base claim 1, which recites inter alia, "wherein the platform kernel section is 
for managing user information, device information and service information ". 

In paragraph 22, the Examiner stated that "the front-end of the platform" lacks 
antecedent basis in claim 9. Claim 9 has been amended to address this issue. 
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Claim Objections - 1.75(d) 

The Examiner stated that "claim 3 is objected to as failing to comply with Rule 
1. 75(d)" because the "specification provides no antecedent basis fo r platform run-status 
manager" Claim 3 has been amended to address this issue. 

The Examiner further stated that "claim 4 is objected to as failing to comply with 
Rule L 75(d)" because the "specification provides no antecedent basis for asynchronous 
requests based on a queue " It should be noted that claims as originally filed are part of the 
disclosure. Claim 4 has been added to the specification to address this issue. 

The Examiner also stated that "claim 6 is objected to as failing to comply with Rule 
1. 75(d)" because the "specification provides no antecedent basis for transforming the XML 
responses into a file format or transforming among communication protocols based on 
script languages of the devices " It should be noted that claims as originally filed are part 
of the disclosure. Claim 6 has been added to the specification to address this issue. 

Claim Rejections - § 102 

(1) Claims 1-2, 4,6, and 8-9 stand rejected under 35 U.S.C 102(e) as being 
anticipated by Lonnroth (U.S. Pat. 6826597). It is respectfully submitted that Lonnroth is 
legally deficient to establish a prima facie case of anticipation against claims 1-2, 4,6, and 
8-9 for at least the reasons cited in the prior Appeal Brief. 

For example, the Examiner incorrectly relies on col. 3, line 61 -col. 4, lines 26 of 
Lonnroth as disclosing 'transforming the device requests into XML requests," as claimed 
in claim 1. Lonnroth at col. 4, lines 7-10 states that "preprocessor 240 receives requests 
and [sic] from clients and generates request objects based thereon." Looking at Figure 2 of 
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Lonnroth , the preprocessor (240) receives the data from three sources: (a) over HTTP from 
the gateway (202), (b) over PROTOCOL A from client (272) and (c) over PROTOCOL B 
from client (270). 

Assuming, arguendo, that the WAP phone (210) of Lonnroth is capable of issuing 
the claimed "device request," then the request will necessarily be a WAP request because 
the WAP phone (210) is a WAP-enabled device. However, the preprocessor (240) would 
not receive the WAP requests directly from the WAP phone (210). Instead, the 
preprocessor (240) would receive an HTTP request, converted from the original WAP 
request, from the gateway (202). Lonnroth at col. 5, lines 18-21 expressly supports the 
above conclusion: "Through its support for HTTP requests, pre-processor 240 appears as a 
web server to gateway 202, and is therefore able to receive HTTP requests that originated 
as WAP requests issued from WAP-enabled devices." 

At best, Lonnroth may be interpreted as receiving WAP requests from the WAP- 
enabled device and converting the WAP requests to an HTTP request. Not until the pre- 
processor (240) generates the request objects from the HTTP requests (not the WAP 
requests) does Lonnroth mention XML documents (see Lonnroth at col. 4, lines 7-10). 
Thus, Lonnroth does not disclose "a device-platform interface, for accepting device 
requests issued by devices. . .[and] transforming the device requests into XML requests" 

Accordingly, claim 1 is not anticipated by Lonnroth . Moreover, claims 2, 4, 6 and 
8-9 are patentable over Lonnroth at least by virtue of their dependence from claim 1 . 

(2) Claims 1-6 and 8-9 stand rejected under 35 U.S.C 102(e) as being anticipated 
by Humpleman (U.S. Pat. 6546419). It is respectfully submitted that Humpleman is legally 
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deficient to establish a prima facie case of anticipation against claims 1-6, and 8-9 At the 
very least, Humpleman does not anticipate claim 1. 

By way of example, with respect to claim 1, it is submitted that Humpleman does 
not disclose or suggest "a device-platform interface, for accepting device requests issued 
by devices wherein said device requests are in a device specific format, transforming the 
device requests into XML requests and then sending the XML requests to a platform kernel 
section via HTTP protocoV\ as recited inter alia in claim 1 . 

The Examiner contends that Humpleman teaches (in col. 19, line 39-col. 20, line 
48) "a device-platform interface, for accepting device requests issued by devices wherein 
said device requests are in a representation mode which is adapted for the devices, 
transforming the device requests into XML requests and then sending the XML requests to 
a platform kernel section via HTTP protocol" It is respectfully submitted that Examiner's 
characterization of the teachings of Humpleman is misplaced. Humpleman teaches (in col. 
19, lines 39-45) a database of device interfaces stored in a database in XML where new 
interfaces can be added to the database and (in col. 20, lines 4-10) transferring one of these 
device interfaces from one device to another. However this is not the same as accepting 
device requests and transforming the device requests into XML requests. Even assuming 
arguendo, that a device interface could be interpreted as a device request, Humpleman 
teaches (in col. 19, lines 39-45) that the interfaces already begin in XML, so there would 
be no need to do a transformation of a device request from a device specific format into an 
XML response, as essentially recited in claim 1 . 

By further example, with respect to claim 1, it is submitted that Humpleman also 
does not disclose or suggest "platform kernel section.. . providing one of a synchronized 
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and an asynchronized service engine", as recited inter alia in claim 1 . The Examiner 
contends that Humpleman teaches (in col. 19, line 39-col. 20, line 48) "platform kernel 
section... providing one of a synchronized and an asynchronized service engine. " It is 
respectfully submitted that Examiner's characterization of the teachings of Humpleman is 
misplaced. The terms synchronous or synchronized do not even appear within 
Humpleman . 

Accordingly, claim 1 is not anticipated by Humpleman . Moreover, claims 2-6, and 
8-10 are patentable over Humpleman at least by virtue of their dependence from claim 1 . 

Claim Rejections - § 103 

Claims 3 and 5 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Lonnroth, as set forth on page 1 1 of the Office Action. Applicants respectfully submit that 
Lonnroth is legally deficient to establish a prima facie case of obviousness against claims 3 
and 5 for at least the reasons presented in the Appeal Brief. 

For example, the Examiner's reasoning that if a product is available for purchase, 
then it must be well known and obvious to use is flawed. Claims must be viewed in their 
entirety. By focusing on an individual claim term and determining that it is available for 
purchase, the Examiner effectively and improperly eliminations interpreting the claim as a 
whole. Further, whether a claim term is available for purchase or is well known does not 
make it obvious to use. For example, a claimed invention may be a novel combination of 
well known components. Under the Examiner's flawed interpretation, he would consider 
such a novel combination to be obvious. This is clearly improper. 

Accordingly, the rejection of claims 3 and 5 should be reversed. 
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In view of the foregoing remarks, it is respectfully submitted that all the claims 
now pending in the application are in condition for allowance. Early and favorable 
reconsideration is respectfully requested. 



Respectfully submitted, 




Frank DeRosa 
Reg. No. 43,584 
Attorney for Applicants 
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